Skip to content

Go: improved coro-sine-sieve (add 2.go) #439

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Go: improved coro-sine-sieve (add 2.go) #439

wants to merge 6 commits into from

Conversation

yunginnanet
Copy link

@yunginnanet yunginnanet commented Jun 22, 2024 •
edited
Loading

Old: 1.go

[AVG] (go_linux_go_latest_default_coro-prime-sieve_1)go:coro-prime-sieve:1000 [32 cores]time: 10.6193ms, stddev: 0.8274214303082389ms, cpu-time: 0ms, cpu-time-user: 0ms, cpu-time-kernel: 0ms, peak-mem: 0KB

[AVG] (go_linux_go_latest_default_coro-prime-sieve_1)go:coro-prime-sieve:4000 [32 cores]time: 143.4305ms, stddev: 2.179981519034819ms, cpu-time: 4126.6666ms, cpu-time-user: 4120ms, cpu-time-kernel: 6.6666ms, peak-mem: 11264KB

New: 2.go (this PR)

[AVG] (go_linux_go_latest_default_coro-prime-sieve_2)go:coro-prime-sieve:1000 [32 cores]time: 1.176ms, stddev: 0.09138451728821445ms, cpu-time: 0ms, cpu-time-user: 0ms, cpu-time-kernel: 0ms, peak-mem: 0KB

[AVG] (go_linux_go_latest_default_coro-prime-sieve_2)go:coro-prime-sieve:4000 [32 cores]time: 3.2914ms, stddev: 0.020078927594205074ms, cpu-time: 0ms, cpu-time-user: 0ms, cpu-time-kernel: 0ms, peak-mem: 0KB

@yunginnanet
Copy link
Author

@hanabi1224

@ivanstepanovftw
Copy link

ivanstepanovftw commented Jul 28, 2024 •
edited
Loading

Contributions are welcome!

@yunginnanet
Copy link
Author

?

@hanabi1224
Copy link
Owner

Sorry, this solution seems very different and incomparable to others.

@yunginnanet
Copy link
Author

Sorry, this solution seems very different and incomparable to others.

i ran the tests, it passes.

it isn't at all different other than the fact that it avoids using channels, which are slow, and instead uses buffered i/o to improve the execution times. it's.. definitely the same thing.

@yunginnanet
Copy link
Author

  • go run 1.go > /tmp/1.go.txt
  • go run 2.go > /tmp/2.go.txt
  • sha256sum /tmp/1.go.txt
    • 18ac898998c81cb9eb52d37be6cd452a3b19babedbdd5cc6e8ffff20e7c2b048 /tmp/1.go.txt
  • sha256sum /tmp/2.go.txt
    • 18ac898998c81cb9eb52d37be6cd452a3b19babedbdd5cc6e8ffff20e7c2b048 /tmp/2.go.txt

it's also quite apparent that the test cases that exist within the repository verify the consistency of the outputs as well...

@yunginnanet
Copy link
Author

Hmm...

Let me know the logic behind your decision!

@yunginnanet
Copy link
Author

yunginnanet commented Apr 14, 2025 •
edited
Loading

@hanabi1224

the primary difference here that results in increased performance is dropping the usage of channels, which are quite slow, in favor of buffered I/O. If you'd like, I can make a version of this that is closer to the original that only implements said change.

# for free to join this conversation on GitHub. Already have an account? # to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@yunginnanet @ivanstepanovftw @hanabi1224